Inter-Fabric Routing

ABSTRACT

A method and apparatus is shown for communicating Fibre Channel frames between distinct fabrics. A proxy zone is established in each fabric with a physically present local device and a remote fabric device. A router creates a proxy device in each fabric for every device not physically connected to the fabric. The proxy devices appear to be directly attached to the router. The router handles all address translations between proxy and physical addresses. When multiple routers are encountered, the ingress router does all address translation. No routing or encapsulation headers are used except when routing between two routers. The source ID and the originator exchange identifier are stored at the egress router for all link requests that require special handling. When replies pass through that router, the destination ID and originator exchange identifier are compared with the stored information. On a match, the reply is specially handled.

PRIORITY

This application claims the benefit of U.S. Provisional PatentApplication No. 60/589,099, filed Jul. 19, 2004.

FIELD OF THE INVENTION

The invention presented in this application pertains generally to therouting of information between remote devices. More particularly, thepresent invention relates to the routing of Fibre Channel frames betweenseparate Fibre Channel fabrics.

BACKGROUND OF THE INVENTION

Fibre Channel is a switched communications protocol that allowsconcurrent communication among servers, workstations, storage devices,peripherals, and other computing devices. Fibre Channel can beconsidered a channel-network hybrid, containing enough network featuresto provide the needed connectivity, distance, and protocol multiplexing,and enough channel features to retain simplicity, repeatableperformance, and reliable delivery. Fibre Channel is capable offull-duplex transmission of frames at rates extending from 1 Gbps(gigabits per second) to 10 Gbps. It is also able to transport commandsand data according to existing protocols such as Internet protocol (IP),Small Computer System Interface (SCSI), High Performance ParallelInterface (HIPPI) and intelligent Peripheral interface (IPI) over bothoptical fiber and copper cable.

FIG. 1 illustrates a variable-length Fibre Channel frame 10. The frame10 has a 4-byte start-of-frame (SOF) indicator 12, which is a particularbinary sequence indicative of the beginning of the frame 10. The SOFindicator 12 is followed by a 24-byte header 14, which specifies, amongother things, the frame source address and the frame destinationaddress. A variable-length data field 16 follows the header 14, whichcan range from 0 to 2112 bytes in length. The data field 16 is followedby a 4-byte cyclical redundancy check (CRC) code 18 for error detection,and by a 4 byte end-of-frame (EOF) indicator 20. Since the data payload16 of a Fibre Channel frame can vary between 0 and 2112 bytes, the totallength of a Fibre Channel frame 10 can vary from 36 to 2148 bytes.

The frame header 14 is twenty-four bytes long, containing six four-bytewords as shown in FIG. 2. The frame header 14 contains a destinationaddress or identifier (D_ID) 60 and a source address or identifier(S_ID) 70. These address fields 60, 70 both contain a twenty-four bitaddress that uniquely identifies a device on a Fibre channel fabric, andare described in more detail below. In addition to these address fields60, 70, the frame header 14 contains a routing control field (R_CTL) 40,a class specific control field (CS_CTL) 42, frame type (TYPE) 44, framecontrol field (F_cm) 46, sequence identifier/SEQ_ID) 48, data fieldcontrol (DF_CTL) 50, sequence count (SEQ_CNT) 52, originator exchangeidentifier (OX_ID) 54, responder exchange identifier (RX_ID) 56, andparameter value (PARAM) 58. The R_CTL field 40 contains routing bits andcategorizes the frame. The CS_CTL, 42 contains class specific controldata or priority data. The TYPE field 44 identifies the protocol of theFibre Channel frame 10. The F_CTL field 46 contains control informationrelating to the frame content such as first sequence, last sequence, orend sequence bits. The SEQ_ID field 48 identifies frames within asequence to assure frame order, and to correlate link control frameswith related data frames. The DF_CTL field 50 specifies the presence ofoptional headers at the beginning of the data payload 16. The SEQ_CNTfield 52 indicates the sequential order of the data frame 10 within asingle sequence or multiple consecutive sequences for the same exchange.The OX_ID field 54 identifies the data communication exchange for theoriginating computer. The RX_ID field 56 identifies the datacommunication exchange for the originally receiving computer. Theparameter/data field 58 can identify link control frames and carryrelated data. Alternatively, for data frames, the parameter/data field64 can contain a data offset value. The third bit of the F_CTL field 46indicates whether the parameter/data field 64 is being used to indicatea relative offset or not.

As explained above, the destination identifier (D_TD) 60 identifies thedesired destination for the frame, while the source identifier (S_ID) 70identifies the source for the frame. These identifiers 60, 70 areconsidered port identifiers or Fibre Channel addresses 80, as shown inFIG. 3. Port identifiers 80 are uniquely assigned to every node in aFibre Channel fabric. Under the standard Fibre Channel switch fabricaddressing scheme, each port identifier 80 is considered to containthree eight-bit words: a domain address or domain ID 82, an area addressor area ID 84, and a port address or port ID 86. Each switch in a FibreChannel fabric is generally assigned a unique domain address 82. Whenswitch ports are directly connected to only a single device, the area ID84 will representing a logical or physical grouping of ports, with theparticular port being identified in by port ID 86. More frequently,however, multiple devices are allowed to connect to a single physicalport on a switch using au arbitrated loop. In these circumstances, thearea ID 84 represents a particular port on the switch, and the port ID86 identifies the particular device on the loop. The addressing schemeallows 256 port IDs 86 and 256 area IDs 84, but only 239 domain IDs 82.This smaller number of domain IDs results from the fact that somedomain/switch addresses are reserved.

Fibre Channel switches use the destination identifier 60 found in header14 to route frames 10 from a source port to a destination port. TheFibre Channel addressing scheme in FIG. 3 allows certain routingdecisions to be made by examining only the eight bits in the domain ID82. Typically, this is accomplished using a lookup table at each inputport. The destination identifier 60 is used as an index to the table,and the table returns the appropriate output port in the switch. Thisoutput port will either be directly connected to the node identified bythe destination identifier 60, or to another switch along the path tothe identified destination. Routing tables are shared between multipleswitches in a fabric over an interswitch link so that the switches canlearn about the nodes and switches that make up the fabric.

Switches uses port identifiers 80 to establish zoning for a fabric,which allows devices to be logically segregated based on function,business departments, or operating system conflicts. FIG. 4 shows anexample of zoning, where servers A and B exist on the same fabric 90 asdisk devices X and Y, and tape storage Z. Disk devices X and Y areassigned to zones 1 and 2, respectively, while tape storage Z isassigned to zone 3. Server A is part of zones 1 and 3, and therefore isallowed by the fabric 90 to communicate with disk device X and tapestorage Z. Server B is part of zones 2 and 3, meaning that this serveris allowed to communicate only with disk device Y and tape storage Z. Inthis manner, zoning prevents server A from seeing or accessing diskdevice Y, and server B from seeing or accessing disk device X. Bothservers are allowed access to tape storage Z. Zoning can be done on aport basis, thereby allowing a particular physical port on a switch tocommunicate with a different physical port elsewhere on the fabric.Unfortunately, this type of zoning is meaningless if the devices areever physically moved from one port on a switch to another.

Alternatively, zoning can occur at the World Wide Name level. A WorldWide Name (or WWN) is a 64-bit name that is uniquely assigned to everyFibre Channel device and port created. By using the MAW to define andimplement the zones, a particular computer or storage device will berecognized by its WWN and properly zoned regardless of the physical porton which the device is found.

The Word Wide Name of a device is made known to the fabric during devicelogin, during which a port identifier 80 is also automatically assignedto the device. The Domain ID 82 of the assigned port identifier 80 willbe the same as the Domain ID 82 of the switch to which the device isconnected. This port identifier 80 is associated with the WWN in a nameserver operating on the fabric 90. Devices log into this name serverduring a fabric and port login procedure, which is required before thedevice can access (or be accessed by) the fabric. The name serverrecords the WAN of the device, and the device's associated portidentifier 80. The name server functionality is implemented in eachswitch on a fabric 90.

Fibre Channel is typically implemented in a fabric made up of one ormore Fibre Channel switches. The purpose of the fabric is tointerconnect the various devices or node ports (N_ports). This isaccomplished by attaching the N_ports to fabric ports (F_ports)associated with a switch in the fabric. Multiple switches communicatewith each to form a multi-switch fabric. Switch to switch communicationlinks takes place over expansion ports (E_ports), and are generallyreferred to as inter-switch links.

The interswitch links formed over the E_ports are used to coordinateknowledge about the physical layout of the fabric, which is used whenrouting Fibre Channel frames 10 over a fabric 90. Switches use a linkstate database and a routing protocol known as Fabric Shortest PathFirst (FSPF) to make routing decisions over a fabric 90. To communicate,this information, Fibre Channel switches are able to communicate avariety of message types, including extended link service messages(FC-ELS), generic service messages (FC-GS), and switch internal linkservice messages (SW-ILS).

Some of the more important extended link services (ELS) are N_PortDevice Discovery: FLOGI-Fabric Login, PLOGI-N_Port Login, andRSCN-Registered State Change Notification. FLOGI enables a device orN_Port to obtain its port identifier 80 and to create a communicationchannel with a switch by setting or exchanging various operationalparameters. PLOGI enables a device to create a communication channelwith the remote device over the fabric by setting and exchangingoperational parameters. An RSCN is issued by Fabric Controller in aswitch to notify all the registered devices when an event occurs, suchas a failed connection with a device or a new device.

The generic services include services performed by the name server inthe switch. For instance, an RFF_ID is a communication sent by a deviceto a switch after the device completes FLOGI. This allows the device tobe registered with the name server database. The switch then uses anRSCN ELS to notify other registered devices of this new device.

The switch internal link services/SW-ILS or ILS) are used to configurethe Switch Fabric, and to build and maintain required routing tables.Some of the most important ILS commands include ELP (Exchange LinkParameters), HLO (an FSPF Hello), LSU (an FSPF Link State Update), SA(an FSPF Link State Acknowledgement), and SW_RSCN (an Inter-SwitchRSCN). The ELP helps to establish a communication channel betweenadjacent E_Port by setting or exchanging operational parameters. All ofthese ILS commands are issued between adjacent E_Ports and use FabricController Fibre Channel address 80 (0xFFFFID) as the S_ID and D_ID forboth request and reply sequences. The HLO command establiShes acommunication channel between two switches between their E_ports. LSUand LSA commands contain Link State Records (LSR) and Link Descriptors(LD), which are used to establish and maintain a synchronized topologydatabase for the fabric and a related routing table. Finally, a SW_RSCNis used to distribute ELS RSCNs is between switches.

In order for Fibre Channel routing to function properly, it is vitalthat every device on a fabric 90 have a unique port identifier 80 andthat every switch in the fabric 90 have a different domain ID 82assigned to it. This effectively limits the size of a network to at most237 switches. Although this is a large number of switches for mostcircumstances, this limit requires the physical separation of one fabricfrom another. It would not be possible to create a world-wide storagearea network similar to the Internet given a limitation of 237 switches.

This reality has recently led several vendors to explore the possibilityof sharing data between separate fabrics. Unfortunately, the requirementfor unique port identifiers 80 has made it impossible to transmit framesbetween fabrics without considerable concern over the port identifiersinvolved in the communication. Since each fabric separately assigns portidentifiers 80, it is likely that there will be some overlap in assigneddomain IDs 82 and port identifiers 80 between the fabrics.

One approach to this problem is set forth in U.S. Published PatentApplication No. 2005/0025075. In this application, the separate fabricsare described as Virtual SANs. While virtual SANs are storage areanetworks that are virtually defined as separate even though they existon the same physical switch, the technique of this application could beused to communicate across separate physical fabrics. The problem ofconflicting domain IDs is avoided by implementing techniques to ensurethis doesn't happen. For instance, the application suggestsadministratively partitioning the domain number space across the VSANsto be connected so that each fabric can assign only a unique subset ofdomain names. Alternatively, the application suggests reserving a subsetof domain IDs to be used only for switches involved in inter-VSANcommunications in this way, both fabrics could be allowed to use most ofthe available domain IDs 82 (such as the first 200) in a standard mannerwithout concern over duplicate usage. The remaining 37 domain IDs wouldbe assigned from a central location, thereby ensuring only one switch inthe combined fabric would be assigned a particular domain ID 82. Allcommunication between fabrics would then be limited to those deviceswhose domain IDs 82 are centrally managed.

A second approach is outlined in U.S. Published Patent Application No.2003/0012204. In this application, multiple fabrics are linked togetherusing gateways so as to allow the combined storage area networks toexceed the Fibre Channel limit of 237 switches in a single fabric. Thisapplication overcomes the problem of conflicting Domain IDs by assigningeach switch a “global address” as well as the local address typicallyassigned in Fibre Channel fabrics. The global address is created bycombining multiple physical switches into a virtual switch, and thenassigning a single global domain ID to the virtual switch group. Whencommunications are made using this global address, the entire set ofswitches is considered a single virtual switch. The ports on the variousswitches are then addressed directly as ports on the virtual switch.Internal communications within the SAN use only local addressing, andare unaffected by the presence of the gateways and the related globaladdresses. When a communication is directed to a device on a separateremote fabric, the communication will use the global address for thatdevice, using the virtual switch ID associated with that device. Therouting for this communication passes through the local or ingressgateway. The ingress gateway translates the source address in thecommunication from the local address created by the local device to thepre-assigned virtual address (with the virtual address typicallycombining multiple physical switches into a single virtual switch). Theingress gateway then transmits this communication oh to a remote oregress gateway physically connected to the reroute fabric. The egressgateway looks to see if the D_ID is a virtual address (to one of itsvirtual switches). If so, the egress gateway translates the D_ID to alocal address. Virtual addresses for a device only make sense outside ofthe physical SAN on which the device is located. Although each fabric isstill limited to 237 switch addresses, the combining of switches onremote fabric into virtual switches means that many more than 237switches can be accessed on the combined inter-fabric.

Unfortunately, neither of the above approaches provides a flexibleenough technique so as to allow inter-fabric data communication betweenFibre Channel fabrics.

SUMMARY OF THE INVENTION

The present invention presents a unique system and technique forallowing the communication of Fibre Channel frames between distinctFibre Channel fabrics. Domain ID conflicts are handled through the useof proxy zoning and proxy devices. A proxy zone must be established ineach fabric that will be linked together. Each proxy zone must includeat least one device that is physically present in the local fabric andone device that is physically connected to a different, remote fabric. Arouter of the present invention then establishes a separate proxy devicein each fabric for every device in the proxy zones that is notphysically connected to the fabric. The proxy devices all use the domainID of the router, thereby allowing all remote devices to appear to thefabric as if they were directly attached to the router. Thus, in eachfabric being connected, proxy devices exist for all the devices that areavailable for communication and are not found on the fabric.

A local device communicates with the proxy device as if it werephysically present on the fabric. The router intercepts thecommunication, and performs address translation on the source ID and thedestination ID in the Fibre Channel frame header. The destination ID istranslated from the proxy address of the remote device to the actualphysical address of the remote device on the remote fabric. The sourceID is translated from the physical address of the local device to theproxy address used for that local device on the remote fabric. A new CRCvalue is also calculated. The altered frame is then transmitted to theremote fabric, where it is routed to the actual physical devicerepresented by the proxy device.

The present invention is able to route communications between aplurality of routers. To do so, one router must be the ingress routerwhile another router is the egress router. All address translationsoccur at the ingress router.

To allow more complicated routing, the present invention proposes aninter-fabric routing header. This routing header is not needed when asingle router connects multiple fabrics, or where a link between tworouters does not require routing. However, the routing header doesprovide mechanisms to detect stale frames, prioritize frames, and todetect routing loops. To ensure that frames having a router header canpass through legacy fabrics, the present invention proposes the use ofan encapsulation header.

Certain link service messages require special handling in the contest ofinter-fabric Fibre Channel communications. These original link serviceframes can be detected by examining the R_CTRL value and the commandvalue for a link service frame. However, many replies to link, servicemessages use the same command value. Hence, it is not practical todetermine which replies require special handling simply by examiningR_CTRL and command values. The present invention solves this problem bystoring at the egress router a source ID and an originator exchangeidentifier for each link service request sent to a device that requiredspecial handling. When replies pass through the same router, thedestination ID and the originator exchange identifier are compared withthe stored information. If a match is found, the ingress (formerlyegress) router can identify the context of the reply and perform therequired special handling.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing a variable-length Fibre Channel frame.

FIG. 2 is a block diagram showing the components of the header of theFibre Channel frame shown in FIG. 1.

FIG. 3 is a block diagram showing the components of a Fibre Channel tortidentifier.

FIG. 4 is a block diagram showing zoning in a Fibre Channel fabric.

FIG. 5 is a block diagram showing a router of the present inventionfacilitating inter-fabric communications.

FIG. 6 is an address translation table with a routing port.

FIG. 7 is a flow chart showing a method of inter-fabric routing.

FIG. 8 is a block diagram showing an EP_port of the present invention.

FIG. 9 is a block diagram showing a VEP_port of the present invention.

FIG. 10 is a block diagram showing an EP_port of the present inventioncommunicating through a B_Port and B_Access.

FIG. 11 is a block diagram showing a pair of routers of the presentinvention facilitating inter-fabric communications.

FIG. 12 is an address translation table with a routing port.

FIG. 13 is a table showing the format of an inter-fabric routing headerof the present invention.

FIG. 14 is a table showing the format of a timestamp.

FIG. 15 is a table showing the format of an encapsulation routing headerof the present invention.

FIG. 16 is a table showing the format of ERP ILS request payload.

FIG. 17 is a table showing the format of ERP ILS accept payload.

FIG. 18 is a table showing the format of EMRT ILS request payload.

FIG. 19 is a table showing, the format of a Mapping_Table_List record.

FIG. 20 is a table showing the format of EMRT ILS accept payload.

FIG. 21 is a table showing the R_CTL value of link services that mayrequire special handling.

FIG. 22 is a table listing the ELS commands that require specialhandling.

FIG. 23 is a table listing the Fibre Channel-4 Link Service Processingcommands that require special handling.

FIG. 24 is a data flow process chart showing the handling of ELS repliesrequiring special handling.

FIG. 25 is a table showing the special handling done on certain linkservices.

FIG. 26 is a flow Chart showing the process of analyzing frames at arouter of the present invention.

DETAILED DESCRIPTION OF THE INVENTION Local Inter-Fabric Routing

The present invention allows devices in different Fibre Channel fabricsto communicate with one another. An example of such communication isshown in FIG. 5, where a router 100 of the present invention is beingused to link together three separate Fibre Channel fabrics or SANs,namely SAN A 200, SAN B 220, and SAN C 240. Inside of SAN A 200 is aswitch 210 labeled Switch SW-1. This switch 210 is connected to therouter 100 with what the switch 210 views as a standard interswitch linkthrough an E-Port. This connection allows SAN A 200 to treat the router100 as simply another switch within SAN A 200. Connected to switch SW-1210 is a Windows server 202. Switch 210 has been assigned domain B0,with the Windows server 202 being assigned a port identifier of ‘B0 0004.’ Similarly, inside SAN B 220 is switch SW-2 230, which has beenassigned domain D0. Attached to switch 230 is a tape device 222, whichhas a Fibre Channel address of ‘D0 00 00.’ Finally, in SAN C 240 isswitch SW-3 250, which has been assigned a domain of B0. This switch 250is assigned the same domain ID 82 as switch 210, which is allowedbecause the two switches exist on two separate fabrics 200, 240.Attached to switch SW-3 250 is Windows server 242, which has beenassigned Fibre Channel address ‘B0 00 00’—the same address as Windowsserver 202.

The router 100 attaches to switches 210, 230, and 250 as another switch,and each fabric sees the router 100 as a switch existing entirely withinits own fabric. In FIG. 5, router 100 has been assigned a domain ID 82of ‘E0’ each of the fabrics 200, 220, 240. Since the router 100 presentsitself to each fabric 200, 220, 240 as a completely independent switch,it would be possible and even expected that the router 100 would have adifferent domain ID 82 within different each fabric 200, 220, 240. Theability of a single physical switch to present itself as separateswitches is well known in the prior art as virtual switch technology. Inthe present concept, each virtual switch is presented to separatefabrics instead of presenting all virtual switches to a single FibreChannel fabric. Alternatively, the router 100 could contain separatephysical switches inside a single cabinet, with actual interswitch linkslinking the switch connected on one fabric to the switch of a differentfabric.

In FIG. 5, router 100 allows Windows Server 202 in SAN A 200 tocommunicate with tape device 222 in SAN B 220, and vice versa. Therouter 100 simultaneously allows Windows server 242 in SAN B 240 toexchange communications with tape device 222. The router 100accomplishes this by creating proxy devices within each of the fabrics200, 220, 240. These proxy devices are virtual devices that present adevice found in a remote fabric to the local fabric. In FIG. 5, router100 has created a proxy device 223 in SAN A and a separate proxy device224 in SAN C, both of which represent the actual tape device 222. Theseproxy devices 223, 224 are both represented inside fabrics 200 and 240as being directly attached to the router 100. Therefore the FibreChannel addresses 30 of these devices share the domain ID 82 used byrouter 100 in those fabrics, which in both cases is ‘E0.’ Similarly, therouter 100 presents Windows servers 202 and 242 as proxy devices 203 and243, respectively, that are attached directly to router 100 inside ofSAN B 220. As such, both proxy devices have Fibre Channel addresses 80containing the same domain name 82 as the router 100.

The proxy devices are created as entries in the name server databasesfound in fabrics 200, 220, 240. In the preferred embodiment of thepresent invention, these proxy devices 203, 223, 224, and 243 will usethe same WWN as the physical devices 202, 222, 242 that they represent.

When the Windows server 202 in SAN A 200 wants to communicate with thetape device 222 in SANE 220, it sends standard Fibre Channel frames toFibre Channel address E0 01 00, which is the address of proxy 223. Theseframes are routed to router 100 by switch 210 based on the domain ID 82of the destination address 60 found in the frame headers 14 of theframes 10. The router 100 receives these frames on behalf of the proxydevice 223, and then submits the frames to SAN B 220 out the connectedto switch SW-2 230. Before submitting the frames, however, the router100 must translate the destination address 60 and the source address 70found in the frames so as to make the frames consistent with theaddresses found in SAN B 230. Specifically, the destination address 60must be translated from the tape device's proxy address (E0 01 00) inSAN A 200 to the device's physical address in SAN B 220 (D0 01 00). Inaddition, the server's source address 70 must be translated from itsphysical address in SAN A 200 (B0 00 04) to the server's proxy addressin SAN B 220 (E0 04 00). More generically, on any ingress to the router100 that is addressed to a proxy address maintained by the router 100,the router 100 must:

-   -   1) translate the destination address 60 from the proxy address        used on the source fabric to the actual physical address of the        device on the destination fabric, and    -   2) translate the source address 70 from the physical address of        the source device on the source fabric to the proxy address used        for that device on the destination fabric.

When the tape device 222 receives these frames, it will respond to thesource address found in the frames, which in this case is the E0 04 00address of proxy device 203. The router 100 receives these responseframes from the tape device 222, translates the destination address tothe actual physical address of the server 202 on SAN A 200 (B0 00 04),and translates the source address to the proxy address used for the tapedevice on SAN A 200 (E0 01 00). The response frames are then placed onSAN A 200, and are routed by switch 210 to server 202 using standardFibre Channel routing techniques. The above example would not change ifthe fabrics shown 200, 220, 240 in FIG. 5 contained multiple switchesand the physical devices 202, 222, and 242 were multiple hops away fromthe router 100. Such hops and the associated routing are standard FibreChannel communications, and are not relevant to the present invention.

The router 100 uses a translation table to determine the appropriatetranslations, such as translation table 110 shown in FIG. 6. Thistranslation table takes as input the receiving port, and the receivedD_ID 60 and S_ID 70 pair. In FIGS. 5 and 6, the port on router 100 thatis connected to switch SW-1 210 is EP-1, the port connected to switchSW-2 230 is port EP-4, and the port connected to switch SW-3 is portEP-2. The router 100 must also perform the proper routing determinationso as to ensure that the incoming frame is directed out of the correctport. This routing determination has been simplified in FIG. 6 byincluding the transmit port in the translation table.

The method used to allow communications between two different SANsdirectly attached to a router 100 is shown in the flow chart 300 of FIG.7. The process starts at step 302, when a frame 10 is received at aingress port to the router 100. The router 100 then accesses translationtable 110 at step 304 to compute a new D_ID/S_ID pair based upon theingress port and the original D_ID/S_ID pair in the frame 10. At step306, the router 100 computes a new CRC value 18 for the frame 10, sincethe change in destination ID 60 and source ID 70 would otherwise cause aCRC error. At step 308, the router 100 accesses a routing database todetermine the appropriate transmission port, from which the translatedframe is then transmitted at step 310.

Creating Proxy Devices

in the preferred embodiment, an administrator assists in the creation ofthe proxy devices. The administrator starts by creating a proxy zone. Todo this, the administrator selects a zone name and prepends the string“PZONE_” to the name. The administrator will then add zone members tothe newly created proxy zone name using zone member identifier type 01h(N_Port_Name). After the Proxy Zone(s) have been created, theadministrator the performs the appropriate steps to get the Proxy ZoneName(s) into the active Zone Set for the fabrics 200, 220, 240. Thezoning created contains both local and proxy devices, but is otherwisesimilar to the zoning shown in FIG. 4. Proxy zones must be created inthis manner in order for remote device communication to occur over therouter 100. In FIG. 5, a proxy zone in SAN A 200 would contain server202 and proxy tape device 223. SAN B 220 would contain a proxy zonehaving tape device 222 and proxy server devices 203 and 243 as members.In SAN C 240, a proxy zone would be created containing server 242 andproxy tape device 224.

After the zone set containing the proxy zone name(s) has been activated,the router 100 assigns a Fibre Channel address 80 for each proxy device.In the preferred embodiment, this address identifier has i) a domain ID82 equal to the local domain ID 82 of the router 100; ii) an area ID 84equal to the port number of the local ingress port (i.e., EP-1, EP-2, orEP-4 in FIG. 5); and iii) a proxy device number starting at zero andincrementing by one. The router 100 then updates the local mapping tableand populates the name server in the fabrics 200, 220, 240 with an entryfor each proxy device. Finally, the router 100 sends an RSCN to theappropriate (registered) ports to announce the new proxy device(s). Ifthe router 100 is operating in remote mode, as described below, therouter 100 will also send a specialized SW_ILS message (an ERMT) to apeer router.

Remote Inter-Fabric Routing Proxy Ports

FIG. 8 shows two routers 100, 102 of the present invention that are ablecommunicate Fibre Channel frames to one another over a Fibre Channellink 400. To accomplish this, the router 100 connects to one or moreother routers through a new FC port type called an EP_port 410, for“Expansion Proxy Port.” This port is much like a prior art E_Port 412used to create interswitch links except that the EP_port 410 must handleinter-fabric zoning activities and the exchange of service messagesbetween routers 100, 102. These messages allow the present invention tooperate and are described in more detail below. Each of the routers 100,102 are shown with standard E_ports 420, which allow the routers 100,102 to connect to the E_ports 430 of standard switches 440. Each router100, 102 also has a switching element 450 which handles the FibreChannel switching requirements of the routers 100, 102. In addition, therouters 100, 102 contain digital logic components 460 that handle theinter-fabric routing components of the routers 100, 102. These logiccomponents (labeled “IFR Function” in FIG. 8) contain firmware orsoftware that is responsible for maintain translation tables 110, 112,for performing the translation of the Fibre Channel addresses 80 inframes 10 destined to proxy devices, and for handling the inter-routercommunications. In FIG. 9, the IFR logic component 460 communicate witheach other over frames passed over the Fibre Channel link 400. Thesecommunications include ERP messages 470, and ERMT messages 480, asdescribed below. The EP_Ports 410 are responsible to handling thecommunication of exchange link parameters ILS messages 490.

The FC-BB2 standard also defines a virtual expansion port known as aVE_Port, which communicates between Fibre Channel switches over an IPnetwork. Like the EP_port, the present invention acids proxy-handlingcapabilities to the VE_Port, and thereby creates a virtual expansionproxy port, or VEP_port 500, as shown in FIG. 9. These ports 500communicate over IP link 510.

The present invention can also utilize B_Port 520 and B_Access 530standards as shown in FIG. 10. To function with this standard, therouters 100, 102 use EP_Ports 410 to communicate with a B_Port 520within the router. The EP_port 410 and the B_Port 520 communicate ELFmessages 490 internal to the routers 100, 102. The EP_Ports 410communicate Check E_Port Connectivity messages (CEC), as expected by theFibre Channel-SW-4 standard. The B_Port 520 and B_Access 530 componentscommunicate with each other over WAN connection 540, and communicate EBP(Exchange B_Access Parameters) messages 550 as expected in the FibreChannel-BB-2 standard.

Multiple Router Configuration

FIG. 11 shows two routers 100, 102 acting to allow communication betweendevices within two remotely located SANs 200, 260. This configurationdiffers from that in FIG. 5 in that the two SANs 200, 260 do notcommunicate with the same router 100. Instead, switch SW-1 210 in SAN A.100 is in communication with router UR-1 100, while switch SW-4 230 inSAN D 260 is in communication with router UR-2 102. In thisconfiguration, traffic from SAN A 200 must pass through both routers100, 102 before it will be received by SAN D 260. Assuming communicationfrom SAN A 200 to SAN D 260, router UR-1 100 is considered the ingressrouter, and rooter UR-2 102 is considered the egress router.

In the preferred embodiment; the ingress router handles all addresstranslation that is necessary for inter-fabric communication of FibreChannel frames 10. The egress router does not perform any addresstranslation, but instead simply routes the incoming frames to thecorrect Fibre Channel port. The ports used by the routers 100, 102 toconnect to each other in FIG. 11 are labeled as VEP-ports 1 and 4. Theseports are used for remote communication over a wide area network, suchas the WAN 106 shown in FIG. 11.

The process for communicating between remote SANS 200, 260 is similar tothe process described above. As before, proxy zones are created in thefabrics 200, 260. Proxy zone 206 contains the WIN2K device 202 and theproxy tape device 263 in SAN A 200, while proxy zone 266 contains thetape device 262 and the proxy WIN2K device 204 SAN D 260. Thereafter, aproxy device entry 263 for Tape device 262 is created in the nameservers of SAN A 200 and a proxy device entry 204 for the server 202 iscreated in SAN D 260.

At this point, the WIN2K server 202 sees the Tape device 262 as justanother local device and may send FC frames to the Tape device 262 usingthe destination address identifier A0 01 00 of the proxy device 263.Router 100 serves as the ingress router, and therefore behaves like therouter in FIG. 5. In other words, the router 100 receives the ingressframe and looks up the D_ID/S_ID pair in its translation table 112, asshown in FIG. 12. The ingress D—ID/S JD pair A0 01 00/B0 00 04 from portE-1 is translated by UR-1 router 100 to D0 00 10/C0 04 00. UR-1 router100 then transmits the frame with the translated D_ID/S_ID pair to UR-2router 102 by sending the frame out port VEP-4. UR-2 router 102 thenreceives the translated frame over its VEP-1 port. Since both thedestination ID 60 and the source ID 70 have been translated for SAN D260, there is no need for the egress router 102 to translate anyaddresses. Instead, the frame is simply routed out of port EP-4 toswitch 270. When the tape device 262 responds to the received FC frames,it will use the destination address identifier C0 04 00 corresponding tothe proxy device 204, since this was the address in the source ID field70 of the received frame. This transmitted frame is sent to router UR-2102, where it is received on port EP-4. Turning to the translation table112, this router 102 will now function as the ingress router, and willtranslate the D_ID/S_ID pair as indicated in table 112. The return frameis sent by UR-2 router 102 on its VEP-1 port and is received by routerUR-1 1.00 on port V EP-4. Router UR-1 1000 then routes the frame withoutfurther translation to switch SW-1 210 in SAN A 200 via port E-1.

The WAN link 106 may be of a variety of topologies. In the preferredembodiment, the topology of WAN link 106 can be selected from SONET(FC-BB-2_SONET, FC-BB-3_SONET, and FC-BB-3_GFPT), Gigabit Ethernet(FC-BB-2_IP, FC-BB3_IP), FC (using the EP_Port of the presentinvention).

Specialized Headers

In order to allow the remote communication shown in FIG. 11 betweenrouters 100, 102, it is necessary to communicate data frames between therouters. To accomplish this, the present invention can use twospecialized headers, the routing header 600 and the encapsulation header640.

Inter-Fabric Routing (IFR) Header

The routing header 600 is not a requirement for the present invention,particularly when a single router 100 directly connects to all fabricsthat are to be linked (as in FIG. 5). In this case, the frames 10 arereceived from a source fabric, the destination and source address 60, 70are translated, and the modified frame is placed onto the destinationfabric by the same router 100. In more complicated routing scenarios,such as that shown in FIG. 11, the use of routing header 600 becomesdesirable but not always mandatory. The communication between UR-1router 100 and UR-2 router 102 may be a direct, point-to-point link overa wide area network. The router header 600 is useful in this environmentsince the routing header 600 provides a method to detect stale frames,prioritize frames, and detect routing loops. However, no intermediaterouting is required. In a third scenario, the present invention sendsproxy communications over multiple hops of inter-fabric routers 100. Inthis case, the data frames may pass through intermediate fabrics that donot contain the destination device. In this case, the translateddestination address 60 created by the ingress router would not beapplicable or recognizable to the intermediate frame. In this case, therouting header 600 is mandatory, since the routing header 600 containsthe destination fabric identifiers 604 and the source fabric identifier614, as explained below.

The format of the IFR_Header 600 is Shown in FIG. 13. The headerincludes the following fields: R_CTL 602 (Routing Control), DF_ID 604(Destination Fabric Identifier), Ver 606 (Version), Pri 608 (Priority),ETV 610 (Expiration Time Valid), HCV 612 (Hop Count Valid), SF_ID 614(Source Fabric Identifier), Exp_Time 616 (Expiration Time), and Hop_Cnt618 (Hop Count). The Routing Control (R_CTL) value 602 is set to 51 h bythe ingress inter-fabric router. The Destination Fabric Identifier(DF_ID) field 604 is set by the ingress inter-fabric router to theidentifier of the destination fabric for which the enclosed frame isintended. This field can be used by devices that exist on intermediatefabrics between the ingress and egress routers to route the frame to theegress router. The Version (Ver) field 606 specifies the version of theIFR_Header 600. For the format specified in table 5 the Version fieldshall be set to 00b. The Priority (Pri) field 608 specifies the Qualityof Service (QoS) value for the frame (see 802.1D-1998). The ExpirationTime Valid (ETV) hit 610 shall be set to one if the Exp_Time field isvalid. The Expiration Time Valid bit, shall be set to zero it theExp_Time field is not valid. The Hop Count Valid (HCV) bit 612 shall beset to one if the Hop_Cnt field 618 is valid. The Hop Count Valid bit612 shall be set to zero if the Hop_Cnt field 618 is not valid. TheSource Fabric identifier (SLID) field 614 is set by ingress inter-fabricrouter to the identifier of the fabric that originated, the enclosedframe.

The Expiration. Time (Exp_Time) field 616 is set to the time at whichinter-fabric routing devices 100, 102 receiving the IFR_Header 600 shalldiscard the received frame. The use of the Exp_Time value as anexpiration timer requires that all inter-fabric routers that process theIFR_Header 600 have the same time value+/− 1 count. The ingressinter-fabric router shall not set the Exp_Time field to a value that isgreater than the resource allocation timeout value (R_A_TOV) used by theingress inter-fabric router and the Exp_Time value shall not be set morethan 1.26*0.25 (i.e., 31.5 seconds) greater than the EXP_TIMESTAMP fieldvalue of the ingress inter-fabric router.

In the preferred embodiment, each inter-fabric router 100, 102 maintainsa local dock that is synchronized to all, other inter-fabric routerclocks to an initial accuracy of +/−0.250 seconds and a running accuracyof +/−20 PPM. The Exp_Time value shall be compared to the equivalent ofbits 37 to 30 in the Network Time Protocol 64-bit timestamp field 520(see RFC 2030), as shown in FIG. 14. This range of bits of the localClock is called the Expiration Timestamp (EXP_TIMESTAMP) value (see FIG.14). The EXP_TIMESTAMP value has a resolution of 0.25 seconds. Aninter-fabric router shall discard a received frame if Inc result of(EXP_TIME-STAMP-Exp_Time) is between 2 and 127 using modulo 256arithmetic.

Alternatively, each inter-fabric router 100, 102 could use the SimpleNetwork Time Protocol (see RFC 2030) to maintain a local clock that issynchronized and formatted for checking the Exp_Time value. The initial,accuracy shall be −0.250 seconds and the running accuracy shall be +/−20PPM. The Exp_Time value shall be compared to bits 37 to 30 in theNetwork Time Protocol (NTP) 64-bit timestamp field 540(FIG. 14). Thisrange of bits in the NTP timestamp field is called the ExpirationTimestamp (EXP_TIMESTAMP) field. The EXP_TIMESTAMP field has aresolution of 0.25 seconds. An inter-fabric router shall discard areceived frame if the result of (EXP_TIMESTAMP-Exp_Time) is between 2and 127 using modulo 256 arithmetic.

The Hop Count (Hop_Cnt) field 618 specifies the number of hops remainingbefore the frame is discarded. The ingress inter-fabric router 100, 102shall set the initial Hop_Cnt value. If an inter-fabric router 100receives a frame with a Hop_Cnt field value of 01h, the frame shall bediscarded. If an inter-fabric router 100, 102 receives a frame with aHop_Cnt field value of 00h, the frame shall not be discarded. Otherwise,each inter-fabric router 100, 102 that receives and forwards the frameshall decrement the Hop_Cnt field value by one if the Flop Count Valid(HCV) bit is set to one.

Encapsulation Header

The encapsulation header is used to tunnel frames containing the routingor IFR header 600 through legacy fabrics. Note that the legacy fabric isexpected to process frames containing an R_CTL, value of 52 h.

The encapsulation header 640 is used when the neighboring routers do notsupport the IFR headers 600 directly. The format of the encapsulationheader (Enc_Header) 640 is shown in FIG. 15. The Enc_Header fields 600are generally identical in definition to the fields defined for theFibre Channel frame header 14 shown in FIG. 2. Because of the commondefinitions between the fields of the encapsulation header 640 and theframe header 14, the encapsulation header 640 may be used to routeframes from N_Port to N_Port within an FC-SW-3 compliant fabric. TheN_Port may be a proxy or translation gateway 100, 102 capable ofdirecting the encapsulated frame to another fabric. FC-SW-4 providesstandard architectural models for the use of encapsulation header 640.The only distinction being that the routing control (R_CTL) value is setby the source of the encapsulation header 640 to the value 52 h.

Sharing of Routing Information

In order for two routers 100, 102 of the present invention to functionproperly, they must communicate with each other about the proxy devicesthat are being established. This communication requires two new InternalLink Service (ILS) message structures: and Exchange Router Parameters(ERP) ILD, and an Exchange Router Mapping Table (ERMT) ILS.

EPR SW_ILS: Exchange Router Parameters

Before using an inter-fabric routing header 600, it is necessary for arouter 100 to determine whether neighboring routers 102 support IFRheaders 600. This is generally accomplished using the Exchange RouterParameters (ERP) SW_ILS.

It would also be possible to determine support using Exchange SwitchSupport (ESS) SW_ILS messages, by specifying an FR capability object.However, ESS messages are sent to a Domain Controller and thereforerequire a Domain ID 82 before they can be sent. In contrast, an ERP issent to the fabric controller.

A fabric controller indicates support for IFR headers by sending ILScontaining an ERP request payload 650 to the destination fabriccontroller, as shown in FIG. 16. The exchange of Router Parametersestablishes the operating environment between the twoInterconnect_Ports. For use in switch port initialization, the S_IDfield in the EPR ILS shall be set to FFFFFDh, indicating the FabricController of the originating Switch; the D_ID field shall be set toFFFFFDh, indicating the Fabric Controller of the destination Switch. TheFabric Controller responding to the ERP request indicates support forIFR headers by sending an ERP SW_ACC payload 660, as shown in FIG. 17.If an EP_Port 410 receives an SW . . . MT (reject) in response to an ERPrequest 650, the EP_Port 410 shall prepend an Enc_Header 640 to allreceived frames containing an FR_Header 600 that are transmitted by thatport 410.

ERMT SW_ILS: Exchange Router Mapping Table

The Exchange Router Mapping Table ILS uses the request payload 670 shownin FIG. 18. This ILS is used to distribute mapping table informationbetween inter-fabric routing capable switches 100. As part of thisprocess, the ERMT is used to register a new proxy device with otherrouters of the present invention. The S_ID shall be set to FFFCxxhdesignating the Domain Controller ID of the Switch that generates theERMT. The D_ID shall be set to FFFCyyh to designate the Domain.Controller ID of the recipient Switch. The Number of Mapping_Table_Listrecords field specifies the number of Mapping_Table_List records 680contained in the payload. The format for the Mapping_Table_List records680 is specified in FIG. 19.

The receiving router may accept or reject the ERMT SW_ILS 670. A ServiceReject (SW_RJT) signifies the rejection of the ER′MT request 670. Anaccept (SW_ACC) 690 signifies acceptance of the ERMT request 670. Theformat of the ERMT Accept payload 690 is shown in FIG. 20.

Handling of Selected Link Services

Certain ELS's and FC-4 Link Services (e.g., PLOGI and ELS's that containan N_Port address identifier in the payload) must be processed bysoftware in routers 100, 102. The reason for this the that the payloadsof these frames may contain instances of the source destination address60 or the source address 70 that is also found in the Fibre Channelframe header 14. While the above description of address translationfunctions appropriately to change the destination address 60 and sourceaddress fields 70, embedded addresses are not automatically translated.Thus, the messages must be specially handled to ensure that the datapayload is altered, if necessary, to correspond, to the appropriateproxy port addresses 80.

Each Link Service request contains a unique command code in bits 31:24of the first word in the payload. The command code shall be read todetermine if special handling is required. Thus, in order to determinewhether a particular frame requires special handling, both the R_CTLvalue and the command code must be examined. The R_CTL values for theELS communications that need to be specially handled are specified intable 700 shown in FIG. 21. Table 710 in FIG. 22 lists the command codesand associated ELS commands that require special handling. In otherwords, an ELS request is identified by an R_CTL value of 22 h. Onceidentified, the command code is examined in table 710 to determine ifthis particular ELS requires special handling. Table 720 in FIG. 23specifies command codes and associated FC-4 Link Services commands thatrequire special handling.

While examining the command code is adequate to determine which ELS orFibre Channel-4 Link needs special handling simply by comparing the codeto tables 710 and 720, the examining of command codes does not work whenexamining the replies to these service requests. This is because eachLink Service Accept reply (LS_ACC) contains the same command code (i.e.,0x20) in hits 31:24 of the first word in the payload. Thus it is notpossible to determine if the Link Service Accept reply needs specialhandling using just the command code.

To solve this problem, the present invention recognizes replies thatrequire special handling by examining the source ii) 70 and theoriginator exchange identifier 54 for each reply and compares thisinformation to earlier stored information. This can be seen in the frameprogression chart 750 in FIG. 24. At step 770, an ELS service request760 is sent from the host to a remote device in another fabric. The ELS760 has a command code of 52h, and therefore is a Discover Address orADSIC ELS (as seen in Table 710 of FIG. 22). This link service request760 is being sent to proxy device address A0 01 00 from a host atphysical address B0 00 04. In the body of the request 760 is the commandcode 8×52 and a port address 80 indicating the N_Port of the originator.The host sets this to its physical Fibre Channel address B0 00 04. Thehost then submits the request to router UR-1.

When the request 760 is received at ingress router UR-1 at step 772, thedestination address 60 is translated to the physical address of thedestination device, and the source address 70 is translated to the proxyaddress of the host in the fabric of the destination device. This isaccomplished using the process described above. The request 760 is alsoidentified as an ELS having a command code of 52h, and thereforerequires special handling. The special handling is accomplished at step772 by translating the originator address in the body of ELS 760. TheELS 760 is then transmitted to Router UR-2 at step 774. At this point,Router UR-2 is the egress router, and it is charged to recognize allframes requiring special handling that it will put out into its localfabric. In this step, as in step 772, the router will identify this ELSby the R_CIL value and the Command code. Although no more specialhandling is required at this egress router, the egress router saves thesource address 70 and the OX_ID 54 for the Exchange in local memory.This is done for each Link. Service request that requires specialhandling. The ELS 760 is then submitted to the device at step 776.

The device response to this ELS by generating a reply 762. This replyalso contains the N_Port address 80 of the originator, which the devicewill set to its physical address D00100. The reply 762 is then submittedto router UR-2 782, which can identify this as an ELS reply by the R_CTLvalue. As the ingress router, router UR-2 will try to determine if theELS requires special handling. The command value of 0x20, however, doesnot allow the ingress router UR-2 to determine if the reply requiresspecial handling directly. Instead, at step 782 router UR-2 compares thedestination address 60 and the OX_ID 52 of the reply 762 with the savedS_ID/OX_ID pair saved in step 774. If there is a match, the router UR-2knows that the reply 762 requires special handling. In this case, therouter UR-2 does perform special handling and the value in the ELS forthe N_Port of the originator is modified to reflect the proxy address ofthe device. Once this is completed, router UR-2 will translate thedestination address 60 and the source address 70 of reply 762 asexplained above. At this point, step 782 is completed, and the reply isforwarded to router UR-1 at step 784. In this case, router UR-1 does notexpect a reply directly to this reply 762, and therefore does not needto save the S_ID/OX_ID pair. The reply is now forwarded to the host atstep 786.

The actual type of special handling that is done on these servicerequest frames varies depending upon the command involved. Processingdetails for each required Link Service is specified in table 790 of FIG.25.

FIG. 26 shows a flow chart 800 that contains the overall process usedfor routing and address translation in the present invention. The firststep 802 is to determine whether or not the destination ID 60 in theframe is a proxy address or a physical address. If it is a physicaladdress, no address translation is required in the header or thepayload. Note that only an ingress router will encounter a destinationID 60 with a proxy address. If it destination ID 60 is a proxy address,step 804 cheeks the R_CTL value to determine if this frame is a linkservice request. If so, step 806 determines whether this link servicerequest requires special handling. If so, step 808 performs anynecessary payload address translations.

If the R_CTL value did not indicate that this was a link servicerequest, step 810 determines if the R_CTL value indicates that the frameis a link service reply. If so, step 812 checks whether a storedS_ID/OX_ID value matches the D_ID/OX_ID of the link service reply. Ifso, step 814 performs the payload translation as described above.

All frames with a proxy address in the destination identifier 60 willenter step 816, where the destination identifier 60 and the sourceidentifier 70 are translated as described above. The CRC value for theframe is recalculated in step 818 and inserted into the frame.

At step 820, the routing for the frame is accomplished. Note that thisis done on the translated destination identifier if the translation wereaccomplished at step 816. If the destination ID 60 were not found to bea proxy address at step 802, then this routing lookup would be performedon the original physical address.

Once the routing has been performed, step 822 determines if this is theegress router. If so, step 824 determines whether this is a link servicerequest that required special handling. This determination is similar tothe determination made at steps 804 and 806. If step 824 does determinethat this frame required special handling, then step 826 saves thesource identifier 70 and to originator exchange identifier 54 locallyfor later comparison with a reply frame at step 812. Whether or not step826 saves the S_ID/OX_ID value pair, the last step in process 800 is totransmit the frame at step 828.

The many features and advantages of the invention are apparent from theabove description. Numerous modifications and variations will readilyoccur to those skilled in the art. Since such modifications arepossible, the invention is not to be limited to the exact constructionand operation illustrated and described. Rather, the present inventionshould be limited only by the following claims.

1.-20. (canceled)
 21. A routing device, comprising: a switch configuredto direct a frame from a first fabric to a second fabric, the framecomprising a source ID corresponding to a first physical port address ofa first physical device and a destination ID corresponding to a firstproxy address of a first proxy device, the first physical port addressand the first proxy address being first fabric addresses; and routinglogic configured to translate the destination ID to a second physicalport address of a second physical device and the source ID to a secondproxy address of a second proxy device, the second physical port addressand the second proxy address being second fabric addresses; wherein theframe is a link service frame comprising a port address in a payload andsaid routing logic further identifies the frame as needing softwareprocessing by examining a header and a command code in the frame, thesoftware processing comprising translating the port address in thepayload.
 22. The routing device of claim 21, wherein examining theheader comprises examining an R_CTL value.
 23. The routing device ofclaim 21, wherein the frame comprises translated source and destinationIDs and is directed to a wide area network (WAN) identified as a path tothe second fabric.
 24. The routing device of claim 23, wherein the frameis prepared for transmission over the WAN as one or more SONET frames oras one or more Gigabit Ethernet frames.
 25. The routing device of claim21, wherein the frame comprises translated source and destination IDsand is directed to a third fabric identified as a path to the secondfabric.
 26. The routing device of claim 25, wherein the frame isprepared for transmission over the third fabric by adding aninter-fabric routing header.
 27. The routing device of claim 26, whereinthe inter-fabric routing header comprises a hop count field and anexpiration timer.
 28. The routing device of claim 26, wherein theinter-fabric routing header comprises a source fabric identifier thatidentifies the first fabric and a destination fabric identifier thatidentifies the second fabric.
 29. The routing device of claim 26,wherein the frame is further prepared for transmission by adding anencapsulation header after adding the inter-fabric routing header.
 30. Arouting device, comprising: a processor that performs softwareprocessing; and a module; wherein the module translates a destination IDwithin a received frame from that of a first proxy address of a firstproxy device to that of a second physical port address of a secondphysical device and a source ID from that of a first physical portaddress of a first physical device to that of a second proxy address ofa second proxy device, the first physical port address and the firstproxy address being first fabric addresses and the second physical portaddress and the second proxy address being second fabric addresses; andthe module further identifying the frame as needing software processingby examining a header and a command code in the frame, the frame furthercomprising a port address in a payload, and the software processingcomprising translating the port address in the payload.
 31. The routingdevice of claim 30, wherein examining the header comprises examining anR_CTL value.
 32. The routing device of claim 30, wherein the framecomprises translated source and destination IDs and the module furtherdirects the frame to a wide area network (WAN) identified as a path tothe second fabric.
 33. The routing device of claim 32, wherein themodule further prepares the frame for transmission over the WAN as oneor more SONET frames or as one or more Gigabit Ethernet frames.
 34. Therouting device of claim 30, wherein the frame comprises translatedsource and destination IDs and the module further directs the frame to athird fabric identified as a path to the second fabric.
 35. The routingdevice of claim 34, wherein the module further prepares the frame fortransmission over the third fabric by adding an inter-fabric routingheader.
 36. The routing device of claim 35, wherein the inter-fabricrouting header comprises a hop count field and an expiration timer. 37.The routing device of claim 35, wherein the inter-fabric routing headercomprises a source fabric identifier that identifies the first fabricand a destination fabric identifier that identifies the second fabric.38. The routing device of claim 35, wherein the module further preparesthe frame for transmission by adding an encapsulation header afteradding the inter-fabric routing header.
 39. A method, comprising:translating, by a routing device, a destination ID within a receivedframe from that of a first proxy address of a first proxy device to thatof a second physical port address of a second physical device and asource ID from that of a first physical port address of a first physicaldevice to that of a second proxy address of a second proxy device, thefirst physical port address and the first proxy address being firstfabric addresses and the second physical port address and the secondproxy address being second fabric addresses; identifying, by the routingdevice, the frame as needing software processing by examining a headerand a command code in the frame, the frame further comprising a portaddress in a payload, wherein the software processing comprisestranslating the port address in the payload.
 40. The method of claim 39,wherein examining the header comprises examining an R_CTL value.
 41. Themethod of claim 39, wherein the frame comprises translated source anddestination IDs and the method further comprises directing the frame toa wide area network (WAN) identified as a path to the second fabric. 42.The method of claim 41, further comprising preparing, by the routingdevice, the frame for transmission over the WAN as one or more SONETframes or as one or more Gigabit Ethernet frames.
 43. The method ofclaim 39, wherein the frame comprises translated source and destinationIDs and the method further comprises directing the frame to a thirdfabric identified as a path to the second fabric.
 44. The method ofclaim 43, further comprising preparing, by the routing device, the framefor transmission over the third fabric by adding an inter-fabric routingheader.
 45. The method of claim 44, wherein the inter-fabric routingheader comprises a hop count field and an expiration timer.
 46. Themethod of claim 44, wherein the inter-fabric routing header comprises asource fabric identifier that identifies the first fabric and adestination fabric identifier that identifies the second fabric.
 47. Themethod of claim 44, further comprising preparing, by the routing device,the frame for transmission by adding an encapsulation header afteradding the inter-fabric routing header.
 48. The method of claim 39,further comprising: identifying, by the routing device, a second frameas a link services request; identifying, by the routing device, a sourceID of the second frame as matching the first proxy address; storing, bythe routing device, the source ID and an exchange ID of the secondframe; identifying, by the routing device, a third frame as a linkservices reply; and translating, by the routing device, a port addresswithin a data payload of the third frame if a destination ID and anexchange ID within the third frame respectively match the stored sourceID and stored exchange ID.
 49. A method, comprising: identifying a firstframe as a link service frame comprising a port address in a payload;storing the source ID and an exchange ID of the first frame; andidentifying a second frame as a link services reply and translating aport address within a data payload of the second frame, if thedestination ID and the exchange ID within the second frame respectivelymatch the stored source ID and the stored exchange ID.
 50. The method ofclaim 49, further comprising directing the second frame to a wide areanetwork (WAN) identified as a path to the first fabric.
 51. The methodof claim 50, further comprising preparing the second frame fortransmission over the WAN as one or more SONET frames or as one or moreGigabit Ethernet frames.